COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\F2\C\{THE COMPILE-TIME SYSTEM OF AL\}=17=3
C00011 00003	\F2\C\{THE RUNTIME SYSTEM OF AL\}=17=3
C00013 ENDMK
C⊗;
\F2\C\{THE COMPILE-TIME SYSTEM OF AL\}=17;=3;


\F0\JThe compile-time system contains world modeling information, the
code-generator, the trajectory calculator, and the emitter.  The
world modeling is described elsewhere.  The code generator and the
trajectory calculator are described here.\.

\F1\CCODE GENERATOR

\F0\JThe principal routine is TSCAN, which generates code for the root of
the bound parse tree and calls itself recursively for the rest.  The
structures in this tree are defined in HALREC[HAL,RHT], page three.
TSCAN is a large IF-THEN-ELSE-IF-THEN chain which determines which of
the various possible structures is present.  If it is some kind of
statement, then appropriate pseudo-code is emitted.  The preparation
of this code may require that code for the evaluation of an
expression.  Such code is prepared in the recursive procedure
EMITEXPR, which performs type-consistency checking (but not constant
folding, which could be done here).  Code for boolean tests is
prepared by EMITBOOL.\.

\F1\CTRAJECTORY CALCULATOR

\F0\JThe trajectory calculator turns motion specifications into
interpretable tables.  At the moment it allows any one mechanism,
that is, one arm or one hand.  Future work will allow any combination
of mechanisms.  The tables are calculated by the following method:\.

\jA thread is made, with a node for each place in the motion
specification, that is, the initial point, the departure, if any, the
via points, the approach point, and the destination.  Arm or hand
solutions are calculated for each node.  It may be that this serial
calculation will lead to flips of the arm.  If this happens, the
proper order is outside-in.  This is because the ARMSOL routine uses
the previous solution to resolve ambiguities in joint 4 of the
Scheinman arms.\.

\jAny deproach points or calculated via points or calculated
destinations must have code emitted to make a cell for them in the
graph structure.  The cell for a departure is marked permanently
invalid.  Its calculator uses the hand position itself, not the place
where the arm was to be at the start of the motion.  The cells for
the calculated via points and the approach point are in the graph
structure in the usual way.  This code must be emmitted at the
outermost practical point in the program: If it is too far in, then
it gets redone too often, and if it is too far out, it might cause
graph structure to hang around associated to non-existent nodes.  In
any case, it is necessary to put such code at a block entry, and to
be sure to get rid of the resulting graph structure at block exit.
The current code does not handle any of this.\.

\jAt this time, the fourth degree polynomials for deproach segments are
calculated, and any given velocity constraints are noted. The
presence of a velocity constraint implies that the acceleration is
constrained to zero.  If the user has supplied a time, it is put in
UTIME, and STIME is computed by the system.  If they are compatible,
STIME is modified to the final decision on the time for the segment.\.

\jAfter the entire thread is made, a global check is made to insure
that the timing is in agreement with the user's wishes.  Then the
thread is divided into chunks, where each chunk is the region between
two velocity-constrained points (the deproach points are such).  A
chunk which has only two points (but not a deproach chunk, for which
the trajectory has already been calculated) gets a fifth-degree
polynomial calculated to match all the constraints.  A chunk with
more points requires splining for the trajectory.  The first step is
to insert one unconstrained point in each of the two longest
intervals.  It has been found that the best place for these points is
almost at the very end of the intervals (.999 of the way to the end)
to minimise overshoot problems.  After the fully unconstrained nodes
have been inserted into the thread, the routine POLY is called to
create the coefficients of the third degree splined polynomial.  It
has been found that using fourth degree polynomials in two of the
segments instead of inserting two unconstrained points leads to
uncontrollable overshoot.  Finally, the resulting trajectory is
emitted.\.

\JThe following conventions are used for arms and joints.  Joints 1-6
are yellow arm (arm 0), and joint 7 is the yellow fingers (arm 2).
Joints 8-13 are the blue arm (arm 1), and joint 14 is the blue
fingers (arm 3).  The angle arrays are tailored to have whatever
joints are needed.  The arm and hand solution programs are told which
mechanism to expect.\.

\JThe current code does not check location, velocity or acceleration
bounds except for location bounds at user-specified places.  Instead,
location bounds are to a large extent insured by the servo.  Velocity
and acceleration can be optimized by rescaling time, in the cases
when the user has not specified any time in the entire motion, nor
any velocities, but this is not currently attempted.\.

\F1\CEMITTER

\F0\JAll code emission is done through the routine EMIT which takes
arguments specifying what output file to use (e.g., pseudo-code or
constant area), the data to output, and whether to treat it as an
instruction, an octal constant, a label declaration, or repeatedly to
produce the rel file.\.
\F2\C\{THE RUNTIME SYSTEM OF AL\}=17;=3;


\F0\JThe runtime system of AL consists of several modules.  These are the
kernel, the interpreter, the control code, and the debugger.  The
kernel was implemented by Botond Eross, the interpreter by Raphael
Finkel, the control code by Bruce Shimano, and the debugger, DDT, by
Jeff Rubin.  These modules will be discussed in order.\.